COMMENT ⊗   VALID 00004 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	A 1. Sexprs as abstract objects
C00003 00003	ideas
C00006 00004	two pronged attack on reliable programming
C00013 ENDMK
C⊗;
A 1. Sexprs as abstract objects
  2. representation: as dotted pairs, and binary trees
  3. recursion, and conditionals as control.
  4. sel, const, and recog as d.s. manipulators

B.1. sequences as abstract objects
  2. sel, const, recog
  3. representation as sexprs
       map data= seq to lists
       map sel, const, and recog
       I/O
  4. beginnings of a.d.s. and  importance of abstractions


C.1. examples of diff and  value
      efficacy of abstraction
  2. stepwise refinement and top-down
     compare with bottom up
ideas
abstraction is slight misnomer since implies moving away from specific,
whereas being specific in first place was wrong.
c.f. "math is abstraction from fortran or 360"


informal-intuitive  → informal d.s. lang
    ↓
mathematical
    ↓			  ↓
numerical math
    ↓
efficiency&          storage struct.
 mach. lang      →   mach. lang


note that in the above there is no need for a physical machine
ideas are as accessible to ancients as mathematics, but it took
computers to bring realization. this might have something to
to with the complexity of the resulting computations(symbolic).

must get away from the coder mentality

abstraction is best seen in the d.s.-non numerical setting since
one of the points of traditional math was to strip structure out of
problem domain and put it into mathematical functions.

why is important: not just theory but must show that this way of thinking
is beneficial. like selling any product: look, smell, feel better,make
you more desireable.

no good lisp program uses car-cdr

compare math and d.s. as disciplines: look at machine independence

on programming:
 1. its difficult!
 2. bugs conception
         cleverness

 3. d.s. programming-very simpl programs on complex data

 4. how to make better programmers


abstraction as a basis for a programmer's assistant
 what is required
  1. proper education and understanding of abstraction
       majority of programmers don't understand abstraction

  2. a programming environment which supports abstraction
       a notation for abstraction
       a system with minimal aids on checking consistency of assumptions
         where possible
       program manipulators
	 the problem is not just with the language. it's in the process
	 of discovery of the program.
two pronged attack on reliable programming
 1 education

major difficulty is poorly educated programmers

compare mathematics training  "mathematical maturity"
 a basic understanding of mathematics: numbers, functions, and algorithms.
 a basic understanding of mathematical rasoning
 a knowledege of the tricks and proof techniques useful in specific contexts
    induction, counting args, etc, contradiction,...
 an intuition about when such tools would be applicable

what is analogous in c.s. --- 
 an understanding of proramming language components: data structures, operations
   and  control structures.
 an understanding of valid reasoning in programming: conditions hold a step-
   then application of an operation or control implies  new conditions hold.

 an intuition about how good programming is done: abstraction and stepwise
  (show examples and results in teaching outlining benefits of such )

 2 tools

  a "specification language" of the (presumptious) power of informal mathematics
which will support abstraction and be amenable to (at least)informal reasoning.
    such is necessary for the proper teaching of programming.

a (initially quite) simple programming environment which supports
or enforces this programming style. Examples to show how even a modest
system can aid immensely.


why?
must teach people to do "reliable programming" from the beginning.

the current interest in "programming methodology" must be viewed carefully.
atempting to uncover "logically valid" rules of programming is admirable,
but premature. Compare mathematics; there we do have well-developed formalisms
for say, first-order formal systems and valid rules of inference are
well known. Indeed, even informal valid reasoning is understood: we can
recognize convincing proofs without formalism. But these areas are not
what we normally include in the subject of "mathematical maturity".
That area is more primitive: "how should i procede to discover a proof --
"what is a reasonable approach to take"..., etc. The art of programming
does note even have this primitive area under control. It is the area 
which Dijkstra is addressing in his papers on structured programming.
But consider all the absurd papers on "Structured xxx" which boil down
to programming without goto, or with block structure. A great many
people still do not understand that what Dijkstra was talking about
was abstraction. Indeed this is what McCarthy's abstract syntax is all about.

Notice that both areas-- education and programming support-- must
be cultivated. Compare theaching a mathematics student first-order
logic without a proper grounding in mathematical fundamentals; he
would not be in a position to apply the tools. We must not condem
programming to a similar fate.  Similarly, if we show the student (or professional)
correct techniques of programming with abstractions, but don't give him
a programming system which reinforces his construction techniques then
our job is only partly complete. To sell such a product we must show that
a user writes better programs with such a system.

A properly constructed specification language has other benefits.
It should be possible to develop proof techniques to help bring
rigor to the informal reasoning process. This task is obviously
quite difficult, but --and perhaps not so obvious-- this task is
secondary to the task of developing informal tools of right reason.
Also these reasonings are meant to be in the informal (meta)
language level, rather than (t)reasonings about programs.
We don't expect numerical analysts to reason about their Fortran programs
we expect that the resoning be carried out at a prior level and
the certified algorithm be transcribible to one of a large set
of programming languages. 
Certainly these reasonings are subject to
errors and certainly the transcriptions can be inaccurate. People
make mistakes.